home *** CD-ROM | disk | FTP | other *** search
/ Aminet 33 / Aminet 33 - October 1999.iso / Aminet / docs / misc / amigapl.9812.lzh / amigapl.9812 / text0661.txt < prev    next >
Encoding:
Text File  |  1999-01-01  |  2.7 KB  |  72 lines
  1. Marcin (radmar) Wasilewski napisal 18-Gru-98 w
  2.  *"Re: Procedura wyszukiwania w assemblerze."*:
  3.  
  4. > Amiga znowu do takich najszybszych nie nale¿y (pomijam tu PPC)
  5. > oczywi¶cie. I je¶li chodzi o procedury, które wymagaj± wiele czasu
  6. > procesora a search na pewno do takich nale¿y to wg. mnie jest sens
  7. > przepisywania takich rzeczy na assembler.
  8.  
  9. Pod warunkiem, ¿e kod w asie bêdzie rzeczysi¶cie szybszy.
  10.  
  11. > C wspaniale siê nadaje do tworzenia GUI oraz skomplikowanych
  12. > algorytmów których napisanie w assemblerze by³o by niewygodne.
  13.  
  14. C siê nadaje do wszystkiego.
  15.  
  16. > Ciekawe jak by chodzi³ player dla MPEGów gdyby by³ pisany w C.
  17.  
  18. Je¿eli by³by napisany przez cz³owieka który dobrze zna C, asembler
  19. 680x0 i kompilator na którym pracuje, to chodzi³by na 95% szybko¶ci
  20. playera asemblerowego. Oczywi¶cie szybki port z Unixa nie da takiej
  21. szybko¶ci, gdy¿ kod z za³o¿enia przeno¶ny nie mo¿e byæ zoptymalizowany
  22. pod konkretny procesor.
  23.  
  24. > Sêk w tym aby znale¼æ umiar i w assemblerze pisaæ tylko te fragmenty
  25. > kodu, które s± najistotniejsze dla szybko¶ci dzia³ania. Mnie siê
  26. > jeszcze tego nie uda³o opanowaæ :) i niestety ca³e progsy lubiê
  27. > pisaæ w asm. :(((
  28.  
  29. Wspó³czujê. Zapanowanie nad czym¶ wiêkszym jest trudne (wiem z
  30. w³asnego do¶wiadczenia). I ciekawe co zrobisz z tym kodem w momencie,
  31. gdy trzeba go bêdzie przenie¶æ na OS 5 na procku xxx.
  32.  
  33. > Je¶li w C uda Ci siê napisaæ prockê szybsz± od tej to od jutra
  34. > przestaje pisaæ w asm i ca³y swój wolny czas po¶wiêcam na
  35. > doskonalenie znajomo¶ci C.
  36.  
  37. Niezale¿nie od tego, czy kto¶ napisze szybsz± prockê w C, to szczerze
  38. namawiam do poznania tego jêzyka :-).
  39.  
  40. > Mam jeszcze kilka pomys³ów na optymalizacje np. jednorazowe
  41. > pobieranie 4 znaków (long word) z przeszukiwanego tekstu. Po
  42. > uprzednim wyrównaniu do warto¶ci parzystej.
  43.  
  44. Taki numer mo¿e siê nie op³acaæ przy procesorach z data cache i
  45. szybkiej pamiêci. Bo trochê manewrów ze SWAP-ami i przesuniêciami Ci
  46. dojdzie. A poza tym w przypadku cache i tak ³adowanie odbywa siê
  47. d³ugimi s³owami.
  48.  
  49. > Umieszczenie w rejestrach ca³ego "wzorca" do wyszukania o ile 
  50. > d³ugo¶æ jego na to pozwala. Teraz jest w ten sposób porównywany
  51. > pierwszy znak wzorca.
  52.  
  53. Pamiêtaj, ¿e tego rodzaju optymalizacje maj± jedn± brzydk± cechê. To
  54. co przyspiesza np. na 020 mo¿e spowalniaæ na 040, czy 060 i odwrotnie.
  55. Chyba ¿e napiszesz wersjê pod ka¿dego procka.
  56.  
  57. > Ale dla pierwszych 6-ciu znaków (tj. 1 znak w jednym rejestrze) na
  58. > pewno bêdzie to szybsze.
  59.  
  60. Na pewno. Ale po pierwsze bêdzie szybsze kosztem d³ugo¶ci kodu, a po
  61. drugie w C te¿ to mo¿na napisaæ. Zadeklarujê 6 zmiennych z atrybutem
  62. 'register' i po k³opocie...
  63.  
  64. PS. Tylko proszê, nie u¿ywaj w procedurze instrukcji MOVE16 ;-)))).
  65.  
  66. -- 
  67. Grzegorz Kraszewski (Krashan/BlaBla) - krashan@amiga.org.pl
  68. PCBDesigner home page - http://amiga.org.pl/~krashan
  69.  
  70.  
  71.  
  72.